AltME groups: search

I don't know what you mean by that. A library or library-binding 
that is interesting to me? Okay let's say I find it important to 
use Red as I do with REBOL on my Apache driven website (no option 
to choose the server with my webhostingservice) to process rebol 
scripts and rsp scripts. I think there is a world of Red users to 
be won if Red could do this, at least we would be able to run Red/Redsp 
scripts on the apacheservers potential customers will have their 
websites hosted on, if you still can follow, they may not be too 
enthousiast changing websitehosting services only because we have 
some fun Rebol/Red scripting to offer. So where would I start?

Andreas: if you know how to improve working dir handling in %rsc.r, 
feel free to do so when you want. We'll adapt the test scripts accordingly.

Not exactly, I read rsc.r as if system-dialect is not set then start 
with the compiler.r script. (after that or else the rest of the script 
follows) but then is has some do other scripts and a modular part 
and the other scripts are modular too. It look all very sound bu 
somewhere <there must be/I expect> a first action or function call.

Pekr, runtimes interpreters are allowed on iOS now, as long as they 
are approved by Apple. What is prohibited is running external scripts 
or scripts downloaded from the internet. All interpreted scripts 
need to be bundled with the app, so the app can be evaluated as a 
whole by the app store gatekeepers. I've given this some thought, 
and it may be possible to cripple an R3-like interpreter sufficiently 
to meet these criteria; all you need to do is put some limits into 
the LOAD and DO mezzanine code. Red could be similarly crippled if 
you want.

Some of you might not have noticed but Red is maturing fast, it justs 
lacks I/O support to be already usable for building small scripts/apps. 
So, even if it is still in alpha stage, we need to come up with a 
plan for building a good user-oriented documentation (there is already 
someone working on the Red formal semantics description). I do not 
want to rewrite the REBOL/Core documentation, but a lot of core concepts 
and datatype will be identical, so, what do you suggest we do for 
documenting Red?

If it would do that, the interpreter could execute the same scripts 
as the compiler unmodified, assuming that any #include files are 
already compiled into the interpreter

I use 'q A LOT on R2 console. In scripts no need that shortcut but 
on console it is a MUST for me :) I open/close R2 console every 30 
seconds to do something like english-turkish translation, to see 
NOW, to use functions manipulating clipboard etc. then Q-it..

AdrianS: Unfortunately, it won't work for me:

From their FAQ:
1.3 Does Everything search file contents?

No, "Everything" does not search file contents, only file and folder 
names.


I find that I search within file contents at least as much as for 
filenames.  It shouldn't be too hard to write a Rebol-based standalone 
exe that would do this.  I'll add it to my growing list of scripts 
to write.

5) "Yes, I think it's very dangerous to claim that Red has Unicode 
and Latin-1 support". Red *has* Unicode support, string! and word! 
value support Unicode, input Red scripts are Unicode, PRINT outputs 
Unicode characters. Latin-1 is used as an *internal* encoding format, 
I don't remember ever claiming that "Red supports Latin-1 for I/O" 
except for the console script (which is wrong, I agree). OTOH, I 
do remember thinking about supporting it at the beginning for printing, 
then I found it cumbersome to support in addition to Unicode mode 
and dropped it during the implementation.

Very much so and connecting it to my MySQL database as well! But 
that is not yet possible at this time. I do not see a use for a form 
if I cannot save information from it.

R2 has all these possibilities, on rebol.org are various examples 
of scripts. For Red we might train our patience muscle of finance 
Nenad in the 'right' direction.

After the mirror game and the chessboard interface, the Red compiler 
script and various cgi scripts and showing all how radio buttons 
work in VID, I can now introduce to you the application to play checkers 
(10x10 international, in dutch dammen). Not bad for a REBOL newbie 
right? Wait a moment with all of your nominations please, because:

There is a tiny issue left with the moving of the pieces when playing 
against the computer but it is minor compared to all other issues 
I have already fixed ;-)


You can download the zip file with the program here http://arnoldvanhofwegen.com/stuff/damscripts.zip

Program is started with do %damb.r and you can play after setting 
the color the computer has to play with on the panel you get when 
you click the top-left button. You can look under the hood and see 
the values the program gives the legal moves. You can put your own 
positions on the board and continue from that point.
Enjoy!

We did a new Saphir / R3 Andoid release.

Changes:
-fixed input text renderin bug

-reworked misc internal threads synchronisation issues to fix possible 
dead locks
-added ACTIVE, INACTIVE events
-added horizontal native scrolling for layouts wider than screen
-fixed screen rotation
-updated demo script (just type DEMO in the console)
-fixed BROWSE bug

-added .r3 suffix to be able open this type of R3 scripts automatically
-other smaller internal fixes


If you want to test it on your phone just run the console and type:

do http://development.saphirion.com/experimental/demo.r


ATTENTION: We changed the directory layout a bit. You find the Andoid 
release here:

http://development.saphirion.com/experimental/builds/android

We added other platforms as well:
http://development.saphirion.com/experimental/builds/

And the root is still:
http://development.saphirion.com/experimental/


Next Wednesday I will give a short talk about our porting efforts 
here via Web-Cast:  http://www.vksi.de/sneak-preview/17072013-android-qs.htm
(German)

OS libraries and R3 libraries are both libraries. However, with GPL2 
they make an exception for linking to OS libraries even if they're 
closed source. With GPL3 they extended that exception to libraries 
that come with a runtime or VM, like Java, .NET, or closed-source 
REBOL. The exception doesn't go the other way though: It's not allowed 
to link to GPL'd libraries with closed code.


Ladislav, the runtime library is used to implement the interpreters, 
and includes the interpreters for that matter, but it's still a library. 
The DO interpreter really doesn't do a lot; it resolves the op and 
path syntax and dereferences words, but everything else is done by 
the functions of the runtime library, which your code is bound to 
at runtime. But for the good news, it's at runtime, so afaict the 
GPL doesn't require you to release your source because of that binding, 
as long as you load the source at runtime, which you pretty much 
have to do at the moment for scripts.


Encapping is a trick, but you can handle that with some limitations. 
Extensions will need to be GPL 2, and that means that they can't 
be used to wrap closed-source libraries unless they were included 
with the operating system you're running on. Encapping regular scripts 
and modules is semantically iffy, but you could handle that with 
a FAQ entry that explicitly says that loading a R3 script doesn't 
count as linking, even if you bind the words to GPL'd values. The 
same FAQ entry would apply to scripts in files, databases, whatever.

Some more Android port info. Since some people around were asking 
if it will be possible to 'encap' scripts with the Android R3 I've 
spent some time researching/prototyping in this area and I think 
I can now answer this question positively. It surely will be possible 
to make "encapper" for R3 on Android and my current prototype results 
show that we'll be able to do it without the need to install any 
SDK or other bloated instalations. It will be just one good-old "encapper 
exe" that will do the job for you.

But I do seem to understand - if I would produce card into PCI slot, 
that would be different situation. Am I right, that under Linux, 
situation is kind of simpler? I have seen some scripts, which blinked 
leds on BeagleBone, by just writing to/reading from particular directory, 
so expect situation under unix systems being kind of - simpler? Or 
once again wrong?

There are some scripts that do that in the script library:
   www.rebol.org/search.r?find=tree

Had to do more than one project with scripts that call themselves 
in R2 to do data extraction from text fields, then call themselves 
in R3 to do processing.

I do like a lot of the REBOL docs, which took time and effort to 
create. Wikis are good for reference information. I agree with Arnold 
that good examples are important. I'll add that giving people a starting 
point is helpful. For example, have example scripts for different 
types of apps or features; CGI, pipe and filter, command line handling, 
etc.


I also think format fragmentation is bad. REBOL's docs are fragmented, 
which makes it hard to know the best place to put something. Being 
able to share data, or have a common doc db that can be rendered 
in different ways, would be great.

I think I should chime in here because I am one of those people who 
are not naturally inclined toward the programming arts. I see that 
many of you realize that the docs have to reach a vast audience from 
novice to expert. That will involve using different methods of presentaton 
and detail. How would you envision the database to look like. If 
we could create something pretty complete then I think all the desired 
above could be accomplished. For what it's worth I use the following:

The rebol dictionary - to look up words and usage I can't remember, 
try to decipher some functionality I need, hopefully find examples.

The View docs - to find out how things works and to remember how 
certain words work

Everything I can find on Parse - This is one subject that is all 
over the place.

Nick's tutorial and Reboltutorial - To learn about topical items 
that one can do in rebol such as sound and animation.

Altme - Asking all of you, especially Henrik, if I can do something 
and how or when something doesn't work.
Rebol.org - To find scripts that do things I need to do

Google - OK, this is generic and possibly obvious but when I am trying 
to figure something out, it's "Rebol ..."

The above items are my  most used resources and not exclusive. Note, 
for me the R3 docs were harder to navigate, especially a few years 
ago when I was looking at the GUI stuff. To me at least they seemed 
all over the place.


So, if one were to analyze that usage, it may help to develop something 
that can accomplish those different needs.

Chris, the easiest way to do what you are trying to do is to use 
sys/load-header, which returns a block of the decoded header object, 
the position of the script after the header (after decompressing 
it if need be), and the position after the whole script (useful for 
embedded scripts. If the script is embedded in a block it will decode 
the whole script and return the decoded block at the position after 
the header, but that can't be helped. R3 scripts are binary, not 
text, so the returned script position is binary.

>> sys/load-header "#!/some/path 1foo^/REBOL []^/script here"
== [make object! [
        title: "Untitled"
        name: none
        type: none
        version: none
        date: none
        file: none
        author: none
        needs: none
        options: none
        checksum: none
    ] #{7363726970742068657265} #{}]


>> to-string second sys/load-header "#!/some/path 1foo^/REBOL []^/script 
here"
== "script here"


Note that it will skip past one trailing newline after the header, 
if one exists.

The module system was almost complete in implementation with the 
last closed-source release, needing only the fixes we (and I mean 
me and you, Andreas) did in the first week of the open source release. 
We have only been waiting for Carl to add that pull request to get 
the current design working as intended, though that request doesn't 
only apply to modules in particular, but to scripts in general. Once 
it is accepted, I need to do another round of optimization, but the 
external effects are set already.

As for that blog, the behavior described there has some practical 
problems. There is nothing in the code itself (I mean the example 
code in the blog, not the implementation code) to indicate that 'last-stock 
is a free variable, but 'if and 'not are not - they are all words 
not declared at the top level of the module (by using them as set-words, 
like in an object) or elsewhere in the code. This means that if you 
want it to have 'last-stock be made local to a module, you would 
have to make 'if and 'not local as well. That works if lib words 
can only be set once, but not if they can be reset, since changes 
wouldn't propagate to the other modules or user scripts (since those 
values are copied to words in other contexts).


We determined that the behavior described in that blog could be useful 
enough to be worth supporting, but had some nasty side effects that 
made it not be what we wanted to do by default. That is why we made 
it an option, in particular the isolate option. If you specify the 
isolate option, your module acts like it does in the blog, and this 
has the effect of isolating your module from all external changes 
to the lib context.

Cyphre, Rebol compression is the same as zip deflate, but it's not 
the compressed part that's more efficient, it's the headers. The 
zip format has some fairly extensive headers, and Rebol compression 
doesn't. We do need compression to support compressed scripts though, 
so we need something. That doesn't mean we can't have something more 
flexible, and if we stick to what we can get from zlib (since we're 
linking it anyway) we can get this flexibility nearly for free.

Some teachers will want to do more and they will begin to learn how 
to write scripts.

SQL is more than the language, it's a storage and execution model. 
As long as we support the storage and execution model we can let 
the SQL servers/libraries process their own scripts. Our own model 
can just translate the R3-style port model (if we decide to do this 
as a port) into SQL operations, with the ability to send SQL code 
directly as a fallback.

Having fun reading through the rebol.org scripts and getting an idea 
how to do things

Carl wrote:

Q: "So, what should be the rules? "

A: Let's lock these down as fast as possible.  It would be great 
to post this in 2005.

Q: "Perhaps a limit on the size of the script."


A: I would like to suggest it has to be a free standing script (not 
a script that grabs other scripts, or other media.  Given AGG, I 
would like to suggest 32K (32,768 bytes) total.  It can be in multiple 
files, but the combined total must not exceed this.  Compatible with 
Rebol View 1.3.


Q: "It needs to be fast to download. We can setup a demo upload/download 
area on the View desktop."


A: I suggest not doing this, but rather put this on a public website. 
 We are trying to invite new developers, the less steps the better. 
 A copy can be on the view Desktop though.


Q: "So, what deadline date? Early January? Before students return 
to school." 


A: I vote the contest ends Dec 31st 11:59.59 (this should be 11:59.60 
but Rebol has a bug representing leap seconds, which happens this 
year).


Q: Who should judge the winner? Vote of the REBOL community or RT 
worldwide staff?


A: I think the people giving the prizes should not do the voting. 
 I can suggest using someone more famous, I can get one of my friends 
like Charles Fleischer the comedian to vote, or better David Brin 
(author of Earth, the postman, Transparent Society), they would both 
enjoy doing the voting I suspect.  


Lastly, I would like to offer the following:  Prolific will put up 
a brand new Xbox 360 (when available).


Instead of having a first and second place, rather, both can pick 
which prize they want.  


So the award wording would be "Win your choice of an Apple iPod video, 
or a Microsoft Xbox 360.  Awarded to the first and second place winners."


Third place should be a choice between SDK license, or Command (and 
in fact, the first and second place winners could chose these as 
well).

RT is re-prioritizing things as they go, because the community will 
get excited about certain things, so it's good go consider putting 
a little time in on those. Other tasks have larger implications and 
take a lot of time to design and code. The /direct issue is a good 
example because they don't want to break file handling code (which 
is used in *many* scripts), nor do they want to just dump in a quick 
change and make matters worse in the long run.

You could use Andrew Martin's map function to achieve this

do http://www.rebol.org/library/scripts-download/arguments.r; 
Needs

do http://www.rebol.org/library/scripts-download/map.r; Instantiate
map func [a][2 * a] [1 2 3 4 5 6] ; supply the function to map
>>[2 4 6 8 10 12]

For POP3 and email fans:


   http://www.rebol.org/cgi-bin/cgiwrap/rebol/documentation.r?script=do-pop-scheme.r


Gives you easy access to LIST, TOP, UIDL, etc. for your spam delete 
scripts or whatever.

context question:
If I inside a context block (an object) in one program write:
do %some-program.r

then I can't reach words and functions in the first program from 
the second. I've also tried to bind words to the first context, but 
without luck. Any ideas? Maybe I should put 2 small test-scripts 
here:

Thanks for the comments.

Please do a mock-up of a proposed reorganization, thanks. Then we've 
got something to compare with.


Latest scripts are available several ways -- most immediate is the 
Script Library home page:
http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-index.r


Script popularity is available for Library members -- thoug the big 
problem here is deciding a meaningful metric (simple dowload counts 
are highly biased for various reasons)
http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-popularity.r

One thing I notice is that there are SEVERAL scripts that do pretty 
much the exact same thing - Text -> HTML, for example.


Perhaps they could be grouped together and people could rate which 
one of them they liked the best?

Problem is that the download page *is* a static URL if you go to 
it directly, eg,
    http://www.rebol.org/library/scripts-download/menu-system.r

But of you click the "download script" link while viewing a script, 
you do go via a dynamic URL -- it creates the static one for you 
and then redirects, eg

http://www.rebol.org/cgi-bin/cgiwrap/rebol/download-a-script.r?script-name=menu-system.r


{What we should do is update the static file whenever a script is 
added or updated. That would fix most instances of this....I'll put 
that on the list, thanks]

I'm chasing some old scripts from Frank Sievertsen, does anyone have 
the following

[lego.r  math-do.r irc-protocol.r reblog.r] all described here http://www.codeconscious.com/rebol/dialects.html

Mike, I'd rather wait until the volunteer who is doing the RSS has 
added the code, rather than bypass their efforts.

Meanwhile, you have several ways of finding out what  scripts are 
new or changed on REBOL.org:
-- we'll sen doyu a tailored email

    http://www.rebol.org/cgi-bin/cgiwrap/rebol/cpt-update-profile.r
    See Section 4, Notices
-- you can peek at your unsent notices to get advanced warning:

     http://www.rebol.org/cgi-bin/cgiwrap/rebol/uns-display-notices.r?ml=yes&my=yes
-- You can use the LDS API:
       do http://www.rebol.org/library/public/lds-local.r

      probe lds/send-server 'list-updated-scripts [5]   ;; what's changed 
      in the last 5 days?
-- Just eyeball the script library home page:
     http://www.rebol.org/cgi-bin/cgiwrap/rebol/script-index.r

Sunada has access.  I put it there since the 4 scripts work together, 
its a very simple way to have a known working (tested) directory 
shared with others.  I don't know how to do this on the Library, 
and not wanting to mess up what is there already (in case someone 
sees a problem), so I stuck them in a simple place for review.

Just seen Vince's reply as a result of Thor prodding the group to 
resync it. Thanks Thor.

<It's strange to have a script who plays a game better than its author>

Straneg, yes......But most of our scripts do things better or faster 
than we could ever manage. That's why we write them rather than employ 
slaves.

Dear Library Team,


   I've only got a single script in the library, but I like it, and 
   I'd like it to live through the R3 update.

Are there any plans for adding explicit rebol versioning to scripts 
that want to stand the test of time?


   Is having multiple binaries on target REBOL platforms a no-no?  Meaning, 
   could the released binary packages for REBOL 3.0 include REBOL 1.3 
   (2.7) executables so scripts don't age out as fast as they did when 
   going from 1.2 to 1.3?  A little bit of configuring on the host OS 
   to start the correct REBOL by extension, shebang, or resource fork 
   on MacOS?  Can DO add a secret launch of older/other binary if a 
   Needs: is specified?

Curious.

That's a nice idea for a sort of "REBOL explainer" application.
But it would be difficult to do in the Library.

The Library does attempt to load and parse scripts -- that's how 
we do the colorisation. But (as with Gabriele's code) we rely on 
REBOL's own reflective abilities to tell us what is a word, function, 
operator etc.

The Library runs an old version of Core (and even if we update that, 
we'd never run a version of View on a webserver) so it does not have 
access to all the information a proper explainer.highlighter would 
need.
Take this script for example:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?color=yes&script=reboldiff.r

'new-line is a valid REBOL word, but it is not colored: that's because 
it is not a word in the version we use.

So sadly, the colorisation at REBOL.or remains a nice bit of eye 
candy rather than a solidly dependable feature.

Gabriel -- Thanks....A word list sounds a good way to go.
***

Jean-Francois -- a hover-over on kewords is certainly do-able and 
could look fun for the first couple of minutes on colorised scripts. 
Though it has drawbacks:
** it'd just about double the size of the page

** I think I'd be serious annoyed by it after 30 seconds -- though 
that may just be me

** lots of hidden-by-css styles (that's the way I'd do it, usng some 
of Eric Meyer's clevernesses) could create confusion for anyone using 
an elderly web browser or screen reader.


A good step in the right direction would be better styles for the 
code as we display it now.....So anyone experimenting with that is 
doing us all a great service ... Amd it would pave the way by creating 
a better foundation for higher cleverness.

Posted docs to the last of the Anonymous scripts.  Starting the  
none  list. Do I change the Author to Anonymous and the version to 
1.0.0 for these scripts, or just leave the headers alone?

Let's look at bit closer at the REBOL header block and licenses. 
In the library (http://www.rebol.org), REBOL scripts have a library 
entry in the header, and it contains a field named "license" with 
about 10 different possibilities. Is it enough to specify the license 
like that, or do we have to put a license text and/or warranty in 
the header of our scripts? Not just in the library but in general. 
Does anyone know, or should we ask an attorney?

We do index the files, and we have several indexes, some built by 
parsing parts of the script. So we can, usually, search for special 
parts of scripts -- like strings or comments.

Part of the difficulty is that there are some scripts that we cannot 
do a 'load or a 'load/header on - they are broken or have an incompatible 
'needs: header. So we cannot add those scripts to the sepcialised 
indexes. They need specialised handling :-)

Watch this space -- I'm fiddling with some code that may partially 
need your need.

How easy is it to edit your scripts after they have been submitted? 
Do you feel comfortable adding the appropriate needs header where 
needed, provided you know enough about REBOL versions to determine? 
Can you flag the appropriate files as problematic?

Doing a search, "Author: Maxim" doesn't briing up his newest script, 
Blood.r   The author field in blood.r is the same as other scripts 
which do show up with the above search.  A search for "Liquid" does 
return blood.r.  Is this a case of "hasn't been indexed yet"?

I attempted to rename button.r to vid-button.r so the new script 
should be deleted and the old one renamed if possible.  As for the 
rest of them...

wizard.r  TO vid-wizard.r
group.r TO vid-group.r    
drop-down.r TO vid-drop-down.r   
dragbar.r TO vid-drag-bar.r       
date.r TO vid-date.r


Since we won't be calling the GUI Dialect in R3 VID the new names 
should make what the scripts do clear even after R3 GUI scripts start 
popping up...

Sunanda: given that R2 uses the host current code page, I think the 
best way would be for the user to convert the script after downloading 
it. On Linux or Mac for eg, UTF-8 is perfect for Core scripts as 
the terminal is UTF-8. On Windows or for View scripts, you'll get 
the host code page displayed anyway, so the user has to do the conversion. 
A tool to do that automatically would be nice (I have the code, it 
will be released soon, but you may need to wait a couple weeks more).

sunanda:  I have a feature proposal for you  :-)


it would be nice to be able to supply a single picture to link with 
the scripts. this image (jpg, png, gif) would have hefty size limitation 
and I think only one image per script should be enough, but having 
this alongside the various listings of the application and within 
searches, new scripts, etc would be really cool.


sometimes, if you see a thumbnail (ui grab, console example, logo, 
output gfx, whatever), it will help raise people's curiosity.  this 
could probably benefit quite a few scripts, which are possibly overlooked.


having a simple search filter of scripts with pics, could also help 
people to quickly find usefull things at a glance.


what do you think?  it could start out really simple, and slowly 
thumbnails could creep into various listings of scripts.

Just tried logging on without success ... is this due to the above 
problems or do I require a password reset? (I've got a couple of 
useful scripts I finaly want to upload).

also, some scripts indexed on google do not have the same url now... 
no example, but just tought I'd point this out... its possible the 
url has changed slightly.

Sorry, no there is not -- not online anyway.

You could download all the scripts and do a search locally with a 
few lines of REBOL code 
http://localhost/cgi-bin/download-librarian.r
(the scripts will all be in the /scripts/ folder)

It'd make some sense to add an [R2] tag to all existing scripts (we 
can do that automatically) and/or [R3//untested] tag.

But let's get some [R3] scripts first,  so we have  a_need_ to make 
the distinction.


A couple of my scripts should be tagged as [R3] -- I just never got 
a round tuit:
   http://www.rebol.org/art-display-article.r?article=j26z

Did you see such line endings in other library scripts, or do you 
think it is just me doing something strange?

Shadwolf: <fine 1024 script burried one on top of another :) nice 
!!!>

They are all tagged in various ways to help catalog and find relevant 
scripts, eg:
   http://www.rebol.org/st-topic-details.r?tag=type//game

The tagging could do with an overhaui, so if you want to contribute 
to the quality of the Library without contributing scripts, then 
being a retagger is one way to achieve that.

I think Sunada has thought to do some download statistics for scripts 
people download.

That's the View cache directory (or sandbox if you prefer), which 
gets set by the installer. Although stuff is downloaded to it it 
is more like the Windows application data directory for REBOL, a 
place for (perhaps untrustworthy) scripts to put their stuff. It's 
not really a default download directory as such.


If you want to change it, the easiest way (for a newbie) is to uninstall 
REBOL, move the entire View directory (not the public subdirectory) 
where you want it to be, and reinstall REBOL, specifying the new 
location. If you are more ambitious, the View root directory is stored 
in the registry and can be changed from there. You can't move the 
public subdirectory seperately from the entire View directory though.


Keep in mind that the View root directory is under Application Data 
for good reasons, particularly to make it easier for multiple users 
on the same computer to use REBOL. It's the standard way to do this 
on Windows, and a good idea overall. 


I tend to leave the View root in appdata where it belongs and then 
set a junction point (sort of like a symbolic link for directories 
on NTFS) in some more friendly location so I can get to the data 
easier. I use the axwLink shell extension for this, which you can 
get here: http://arniworld.de/downloads.htm

Carl made MakeDoc and started a project some months ago to define 
MakeDoc2, but it seems, the group fail to make progress, so Carl 
wrote something about it lately and published some scripts. As I 
see it, MakeDoc has some bad ideas around commands like \note /note 
\table /table and so. Those things should be strictly based on the 
hierarchical datamodel, else users of the format WILL make errors, 
as we see it with HTML, XML and the like. And MakeDoc2 also miss 
bold, italic and the like, which is done as HTML tags. I need to 
make a lot of specifikation and documentation for my projects, so 
I desided to make my own format, that suit my needs. I don't know 
yet, what I should do with it yet, but I'm going to do it. :-)

Yes, I know make-doc-pro, but I haven't looked at it in depth. I'll 
do that. I've also started to write a comparison of MakeDoc2 and 
my new NicomDoc format - what thoughts, that made me start work on 
an expansion (as I see it) of MakeDoc2.


About other formats already there, I plan to make conversion scripts, 
so you can go from one format to the other. Of course I hope, we 
can all agree on one final format, that'll suit us all.

I'm going on skivacation for a week, but I desided to put my work 
so far on the NicomDoc document format up on my website. It's NOT 
version 1.0 yet, so some features are not supported. I'll write a 
short specification in a moment.


Parsing a NicomDoc document to HTML goes in two passes, first the 
raw document is converted to RebXML format. This is done by this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/nicomdoc.r


Next the RebXML version is converted to HTML. This is done with this 
script:
http://home.tiscali.dk/john.niclasen/nicomdoc/rebxml2html.r


I've also made a little script, that will do the whole conversion 
in one go by calling the other scripts. It works much like calling 
makedoc2.r, and it can be found here:
http://home.tiscali.dk/john.niclasen/nicomdoc/ndoc.r


Those of you, who want to work with this format, e.g. make VID output, 
should work from the RebXML version of the document (after first 
parsing from raw document to RebXML with the first script), because 
this script handle all the complicated rules, so the RebXML version 
is much easier to work with.

REBOL/View 1.3.50.3.1 14-Oct-2005 Core 2.7.0
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> change-dir winpath-to-file "C:\rebol\scripts\pdf_maker"
== %/C/rebol/scripts/pdf_maker/
>> do %pdf-maker.r
>> myLayPdf: layout-pdf [[textbox ["This is some text."]]]
** Script Error: Cannot use add on none! value
** Where: make-pages
** Near: pid: (2 * length? pages) + i
foreach
>>

There was a reason - already forgot it.

The only thing in user.r was the function above (except set-net) 
- and I removed it ;-)
But:
REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3
Copyright 2000-2005 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> change-dir to-rebol-file "C:\rebol\scripts\pdf_maker"
== %/C/rebol/scripts/pdf_maker/
>> do %pdf-maker.r
>> myLayPdf: layout-pdf [[textbox ["This is some text."]]]
** Script Error: Cannot use add on none! value
** Where: make-pages
** Near: pid: (2 * length? pages) + i


Could it be connected with that I am starting rebol with view.exe 
-i ?

I think you can do that. cronjobs are normal scripts that are carried 
out. they reside in a table of cronjobs which basically is a shell 
script with some time and date information added

I would like to know the result guys, as I am about to create scripts 
for the partner site, and if I fail, bye bye rebol - the trouble 
simply is - they told us - if you want to sync data to us, prepare 
import utilities for us. So - I would still have to do the job, just 
using php or simply something else - which would be a big time loss, 
as I never used it before ....

I need to prepare some installation instructions for our polish partner. 
I will do some scripts to access mySQL on their server, using rebol, 
but I will not have access to the site. So I want to be well prepared, 
so they don't get annoyed after writing them tens of times "try that, 
try this" etc. :-)

the wonderful world of linux... what I had to do was to make scripts 
as shellscripts with the shebang line at the top with the path to 
the rebol executable. there is a mention of this in the Rebol/Core 
manual here: http://rebol.com/docs/core23/rebolcore-2.html

This should work across the various desktops.

I used to do so for python scripts... it was really cool... no one 
saw the shell, until a crash occured, in which case all the prints 
where available for copy/paste.

aah! cgi-scripts on linux do not work then.

Personaly I do not like M$ as it is monster. ;-)

But in my last and current work I am not responsible on which web 
server to chose and therefore neither for security of web server.

And I am trying to separate my  resposibility and SP responsibility, 
but of course there is cases when they overlaps.

I am just trying to find  as much as possible info about security 
of web servers and it does no matter if it is M$ or not .

My first installations was on IIS 5.0 in intranet - so I relied on 
firewall. The last case is in public internet. 

So I think if there are no possibility to upload danger cgi scripts 
or pass danger code to existing scripts, than from my side I did 
all.

Nicolas, try this:
do http://www.rebol.cz/~cyphre/scripts/r2/toys/imap-cli.r


this is very simple CLI for access to google IMAP server (others 
should work too).


Once you run it you can just type at thh prompt IMAP commands. Snippet 
of example session:

Script: "IMAP CLI in REBOL" (none)
{* OK Gimap ready for requests from 90.183.64.72 27if531665fxm.20
}
IMAP>>login user pass

{* CAPABILITY IMAP4rev1 UNSELECT LITERAL+ IDLE NAMESPACE QUOTA ID 
XLIST CHILDREN X-GM-EXT-1 UIDPLUS COMPRESS=DEFLATE
A0001 OK [user-:-gmail-:-com] authenticated (Success)
}
IMAP>>examine inbox
{* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS ()]
* OK [UIDVALIDITY 2]
* 5989 EXISTS
* 0 RECENT
* OK [UIDNEXT 70472]
A0002 OK [READ-ONLY] inbox selected. (Success)
}
IMAP>>

Hope this can be useful...

The trick for me is to reconcile the she-bang line, not only for 
different servers and OSs *but* also with different scripting languages. 
 Using one she-bang line on the test machine and a different one 
on a live server is full of potential errors, regardless of the language. 
On apache/windows the following line being enabled: "ScriptInterpreterSource 
registry" tells apache/windows to find an association in the registry. 
Well, there is no rebol/core installation procedure to do it, and 
the registry entry appears to be different from windows 98/IIS, and 
I haven't been able to figure it out. I need to be able to run scripts 
from rebol, python and perl on this machine *and* to be able to upload 
any of them to a unix/linux server. so ..... I installed rebol and 
user.r in c:\usr\bin, installed python at   d:\python23 *and* copied 
python.exe to c:\usr\bin. So far rebol and python are both working 
using #!/usr/bin/rebol and #!/usr/bin/python respectively as the 
she-bang lines (with ScriptInterperterSource turned off). I will 
later try that with perl and see what happens. If that works, then 
I have a solution. However,  it seems to me that the rebol installation 
should provide proper registry entries to by-pass the she-bang line 
as perl and python do.

do http://www.rebol.org/library/scripts/menu-system-demo.r

I have recently started testing with Rebol/View 1.3, and decided 
to

purchase Rebol/SDK.  I have a function in one of my scripts that 
was
working in View during testing, but as soon I start using the SDK
binaries it no longer... um... functions.


In the function, I am trying to set a value in an array using an 
index
variable.

In view, I could do:
   values/:index: value
But in the SDK, I get:
   ** Syntax Error: Invalid word -- :index:

Again, any help would be appreciated.

Thank you,
robert w. dumond

Most of the GUI work I do does not use VID or networking, so enface 
without any of the view-* or prot-* scripts is what I want. I do 
not want to use a loader front-end based on rebview that includes 
all this code. The cost in executable size may be small (less than 
100Kb), but it's the start-up time and memory cost that I like to 
get as lean as possible. This will become more of an issue if and 
when REBOL is ported to small memory footprint devices.

Also note that the evalScripCodeFunc is when rebol scripts calls 
DO_BROWSER function. Not needed for basic port.

Do you look for a return value from those scripts to make sure it 
went okay?

I've been reading the docs both for the preprocessor and for the 
newer include.r script but I'm a bit confused, I wonder if someone 
could help clear it up for me. Here's my situation. I have view and/or 
SDK installed on a PC and a script sitting on my desktop. This script 
needs one or more library scripts which are available from web servers. 
How do i write the start of the script so that I can do all of;

1) Double click and have it run in view

2) Run the preprocessor so that I have an all in one script ready 
to run/copy somewhere

3) Encap it by dragging and driopping it on encmdview.exe or similar


I want to be able to do this without changing a single character 
of the script. I want to access the library files from a web server 
because here at work I often write scripts on various different servers 
and prefer to keep one copy of the libs centrally and not downloaded 
onto each machine.

What do I have to change in my scripts so they will work with current 
version of encap?

Windows keeps track of all the programs used to open a particular 
file extension. Just right click the script then choose:

	Open With | Choose Program


and browse select the file you want to open it with (checking the 
"Always use ..." option if you want to permanently associate it). 
Thereafter, this file is displayed whenever you right-click and bring 
up the "Open with" menu. On my system I have multiple REBOL versions 
and editors available so I can easily choose how I want to open a 
script.


Anton: if your .R scripts are associated with your editor, how do 
you run them? Console session and do?

I have one recomandation to do for the menu widget http://www.rebol.org/library/scripts/menu-system-demo.r

Encap: You have encapping with external scripts in detective? should 
be a selfmade do then, to check authoirity. But would extract some 
files when running.

Doing my first steps with REBOL I tried to do something with XML

(reading/eventually modifing/writing). I looked for some scripts 
helping
me to do this and found:

1. xml2rebxml/rebxml2xml:
    I got the following problems:
    - missing/loosing comments
    - missing/loosing elements - that's realy serious
    my steps were:
      my-doc: xml2rebxml read %simple.xml
      write %simple2.xml rebxml2xml my-doc


    The second documents finishes outputting elements after some comment
    block in
     the source xml doc.

 2. xml-parse/xml-object:

     The versions I found on the reb library didn't work, I used some

     older versions from rebXR-1.3.0, I've got my objects, but it would 
     be

     nice to have a third module like xml-write to get the object tree
     back to xml. Is somebody developing something like this?

 3. mt.r:

     I tried to figure out how it works. Basically I can write some XML

     based on a REBOL block but I couldn't figure out how to define the

     rules about elements and attributes. Where can I find an example

     about writing for instance svg with mt.r, how looks the coresponding
     REBOL block and the rules for svg?


Where can I find more about xml and REBOL, I think it would be very 
nice
to have some REBOL scripts, doing things like 
   some-elem: xml-create [ elem "foo" namespace "myns" attribs [
                                     bar "something"
                                     xyz "123"]
                                     ]
   xml-modify [ elem another-elem append some-elem ]
and finally
   xml-write %mynewxml.xml my-doc


Is somebody developing something like this with REBOL? Some scripts 
giving

me the same comfort in REBOL like maybe XOM (http://www.xom.nu) is 
giving
for XML in Java. Of course done with some nice REBOL dialects?

What is the above mentioned "EasyXML" - is it available for use/testing?

Thank you for any tips, carsten

Uniserve is very nice, I have been using it to prototype/test before 
I upload to actual server.  It broke my heart it was gpl.  BSD is 
very good choice.  Free software should not be restricted, and GPL 
has too many of those.    makedoc/spec is the killer app,  and in 
that intensional programming vein is coursing all the best documentation, 
and REBOL  does a fine job of documenting itself because it is so 
semantic by nature.  To understand how to use a moderately complex 
system like a full-featured web server, it is going to be important 
to capture the thinking of those who wrote the code.  REBOL parsing 
allows all information pertaining to the code to be right there with 
the code,  and a function of  DO -ing anything.  the standard documentation 
scheme should follow how REBOL [] headers work, and simply have the 
makedoc embedded within the scripts.

Do you really need the GNU make to generate all the .r scripts ??

As a newbie, what suggestions do you have for me to debug my rebol 
scripts.  For example, I have a script called "Convert_to_Table" 
that I am just starting to write.  I can execute it -stand alone- 
and see the results of the run, but what I would like to do is be 
able to see what the console has for any values.  In other words, 
when I double click the "Convert_to_Table" I can see the results 
but not ask the console questions like print Count or the like.  
How do you suggest a newbie debug a script?  Should I go into console 
first and then perform a "do Convert_to_Table" and then be able to 
ask questions of console, or is there another way?.

Rebolers are sick of waiting.

.... good Rebolers don't wait. At least I have so many R2 scripts 
which I would like to improve... I really don't have to wait for 
R3.. with R3 I will be able to do other optimizations but these are 
not necessary for the functionality.

If you had persistent connection and if sqlite does some caching 
it could be faster, but if you need to open a connection on each 
request I think it would be much slower because that is more expensive 
(I assume).. it probably also matters how many scripts do you need 
to run per request

Security Issues:

- We should to be able to restrict with the secure native what files 
and dlls the plugin can access.

- The default security of the RT-provided plugin (not encapped by 
a third-party) should prohibit any access to any local files or libraries 
at all, even in the same directory as the script, and prohibit access 
to third-party network addresses as well. Or at least ask.

- There should be some way to access the site's cookies from the 
plugin, because there shouldn't be any other way to store local data 
on the client computer's hard drive. Anything short of that will 
be a security hole.

- There should be no way to reduce the default security of the plugin 
through the use of plugin params.

- Any attempt to reduce access should prompt the user for permission, 
in terms a non-technical user can understand. This means rewriting 
the security dialogs to be more user-friendly.

- Any relaxation of these default security restrictions should require 
encapping the script.

- A user (or their lawyer) should to be able to (perhaps through 
RT) track down the author of any encapped script.

- An encapped script should count as a seperate plugin as far as 
the user is concerned, at least as far as permission-to-install is 
concerned.


Basically, the default security of the plugin should not allow scripts 
to do anything you wouldn't want your worst enemy to do on your computer. 
People will try to use this plugin for advertisements, for webbugs, 
for spyware, for every nasty thing that you aren't evil enough to 
think of. Avoiding that kind of thing should be the focus of the 
default security settings. Anything less will make the plugin unsafe 
to install.

You can do a lot in those restrictions - look at Google. Beyond that, 
that's what the SDK would be for - not because of the source obscuring 
as much as so that the developer of scripts that can access your 
system could be tracked through your license.

What we may need is a way to partially encap scripts:

- Encrypt them using the SDK licensee's key in a way that can be 
decrypted by the plugin and traced to the licensee.

- Decrypt them with RT's plugin rather than bundling them with native 
code.

- Prompt when loading them the first time, perhaps with company info 
like IE does with ActiveX controls.
- Give encapped scripts a sandbox directory like rebsite scripts.

- Let these scripts do what they must, knowing that if they are malicious 
you know who to sue.

Anonymous scripts shouldn't be able to do any more to your system 
than JavaScript in the browser can.

Anonymous scripts should be able to read through the browser cache, 
at least for files from their own site, but should assume that those 
files won't necessarily persist beyond the browsing session. You 
don't want to give them a sandbox that doesn't have its space limited 
by the browser's existing facilities, for security and privacy reasons. 
You definitely don't want anonymous scripts to store more than cookies 
on your systems.


The guideline you should set for default behavior of anonymous scripts 
is to limit it to the activities that would be OK for deliberately 
malicious code to do. Assume that all anonymous code is out to get 
you until proven otherwise. This is a browser plugin you know - it 
will be used in banner ads.

At least that is the case with anonymous applets. Signed applets 
may be able to do more, as signed REBOL scripts should be able to 
do as well.

Ryan, that sounds like just the kind of thing that signed scripts 
should be able to do.

Hi all....here's an update on what we're working on for the next 
plugin release:

 * Multiple instances -- this feature will allow you to run multiple 
 plugins side-by-side within the same IE or Mozilla process.

 * Automatic updating -- no more uninstall! (aren't we all thrilled? 
 :)). This will be the last update you will have to install manually 
 via uninstall/reinstall; future backwards-compatible updates will 
 come automatically (with user consent).

 * Smooth install on Mozilla -- FF and other Mozilla.org-based browsers 
 will have a smooth install experience similar to IE.

 * do-browser in Mozilla -- you will be able to interact with the 
 HTML page from your REBOL scripts in Mozilla browsers.

 * Last, but not least: Opera 9 support -- the plugin will be compatible 
 with Opera 9, although the install process will not be as smooth 
 as Mozilla & FF.

Josh's aforementioned secure source code was something I suggested. 
The other part of the suggestion was that every secure script would 
be cryptographically signed by an SDK license key, or some other 
way for RT to trace the author of the script. Only those signed scripts 
would be allowed to store persistent data in a sandbox without the 
attempt to do so prompting the user with a security requestor.

Scripts that aren't cryptographically signed (anonymous scripts) 
would be limited in what they can do on your system.

do they have time and resources to sift through thousands of expertly 
crafted scripts per day? (just being positive about a future scenario 
:-))

for security: Until the plugin is fixed, could it show an own page 
first where it ask "do you really want to run this script?". then 
it would be still easy to show a demo to friends, but not for others 
to sneak scripts in.

Is there any point in the REBOl.org Script Library supporting the 
plugin any more?


There are 15 scripts that are tagged as runable in the plugin. But 
none of them do in recent browers.
    http://www.rebol.org/st-topic-details.r?tag=platform//plugin